| 翻訳と辞書 |
| Utility Abstraction Pattern ： ウィキペディア英語版 |
Utility Abstraction Pattern
Utility Abstraction is a design pattern, applied within the service-orientation design paradigm, which advocates designing services〔(Services )〕 that provide cross-cutting〔Functionality that is based on logic which is not related to any particular business process e.g. the requirement to log incoming messages may be required by multiple business processes.〕 non-business 〔Functionality that is based on logic which is not directly related to the automation of a business process e.g. the invoice processing business process may indirectly require a helper functionality for sending out emails, so in this case, the email functionality is not directly required, however, to complete the processing of invoices, the parent processing logic makes use of this non- business related functionality.〕 related functionality, which can be positioned as utility resources to automate multiple business processes.
==Rationale==
In order to automate a business process, the required solution logic is based on the corresponding business work-flow and the business rules. Although the business specific logic can be derived from the business domain, however, in order to complete the automation of the business process, some general purpose logic is normally required that cannot be derived from the business domain. Such logic usually offers low level generic functionality that is commonly required to automate multiple business processes e.g. logging incoming service request messages for metering purposes. As different business processes are analyzed, the corresponding general purpose utility logic is identified and delivered as part of the main business processing solution logic (within the same service). Although this method works fine for fulfilling the short-term project requirements, it gets difficult to keep different services, each containing some level of utility logic, in-sync in the long run when it comes to making a change to the contained utility functionality e.g. due to an upgrade of the underlying technology resources (databases, legacy systems). On the other hand, it not only denormalizes the service inventory,〔(Service Inventory )〕 due to the redundancy of the utility logic, but also loses the opportunity of making such general purpose logic available for reuse to automate multiple business processes.
In order to address the above issues,〔Mauro. et al. (Service Oriented Device Integration - An Analysis of SOA Design Patterns. ) (), pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 6 April 2010.〕 the Utility Abstraction design pattern dictates the separation of generic processing logic from the business process-specific logic into a separate group of services known as the utility services.〔(Service Layer Types )〕
抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』
■ウィキペディアで「Utility Abstraction Pattern」の詳細全文を読む
スポンサード リンク
| 翻訳と辞書 : 翻訳のためのインターネットリソース |
Copyright(C) kotoba.ne.jp 1997-2016. All Rights Reserved.
|
|